-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce config map watcher for feature flags #2637
Introduce config map watcher for feature flags #2637
Conversation
Hi @adshmh. Thanks for your PR. I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This PR cannot be merged: expecting exactly one kind/ label Available
|
2 similar comments
This PR cannot be merged: expecting exactly one kind/ label Available
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
/ok-to-test |
The following is the coverage report on the affected files.
|
210c5eb
to
19e2cf0
Compare
The following is the coverage report on the affected files.
|
19e2cf0
to
dd6ff21
Compare
The following is the coverage report on the affected files.
|
This PR cannot be merged: expecting exactly one kind/ label Available
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for working on this, I've been wondering why we used the configStore for pipelineruns and not for taskruns too.
My main questions on this is whether we really need the extra module, or if we could just use the existing one and add extra flags to it?
The other question I have is about the existing config store. The testing methods for the pipelinerun controller do not support having configmaps as test data to seed. I think this probably means that we had less coverage there. Would it make sense to add the same feature there? (possibly in a different PR)
pkg/apis/config/feature_flags.go
Outdated
@@ -0,0 +1,78 @@ | |||
/* | |||
Copyright 2019 The Tekton Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: this should probably be 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed.
The other question I have is about the existing config store. The testing methods for the pipelinerun controller do not support having configmaps as test data to seed. I think this probably means that we had less coverage there. Would it make sense to add the same feature there? (possibly in a different PR)
Sure. I will review the pipelinerun
controller code and submit a PR to cover this.
@@ -0,0 +1,99 @@ | |||
/* | |||
Copyright 2019 The Tekton Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed.
@@ -0,0 +1,22 @@ | |||
# Copyright 2019 The Tekton Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed.
@@ -0,0 +1,26 @@ | |||
# Copyright 2019 The Tekton Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed.
@@ -0,0 +1,22 @@ | |||
# Copyright 2019 The Tekton Authors |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed.
return false | ||
} | ||
return true | ||
func ShouldOverrideHomeEnv(ctx context.Context) bool { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice :)
Clients: c, | ||
}, cancel | ||
}, cancel, stopCh |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already return a cancel function to tests, so it doesn't feel ok to pass them an extra channel to stop.
I wonder if it would be possible to change SetupFakeContext
to handle the configMapWatcher instead, but at least we should be able to return something like:
, func() {
close(stopCh)
cancel()
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed. I will take a look and submit a PR if there is a way to avoid dealing with the channel altogether, i.e. letting SetupFakeContext
handle it.
@@ -479,6 +519,184 @@ func TestReconcile_ExplicitDefaultSA(t *testing.T) { | |||
} | |||
} | |||
|
|||
func TestReconcile_FeatureFlags(t *testing.T) { | |||
taskWithEnvVar := tb.Task("test-task-with-env-var", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be great if you could add a comment that describes what the test aims to verify!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. Fixed.
return &Config{ | ||
Defaults: defaults, | ||
Defaults: defaults, | ||
FeatureFlags: featureFlags, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you clarify why we need FeatureFlags
to be separated from Defaults
?
AFAIU feature flags are a special type of defaults, that take a boolean value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for working on this, I've been wondering why we used the configStore for pipelineruns and not for taskruns too.
My main questions on this is whether we really need the extra module, or if we could just use the existing one and add extra flags to it?
Thank you for the detailed review. Please let me know if the following sounds correct. I'd be happy to update the PR if needed to merge the two sets of options.
I have implemented the draft this way mainly because the feature-flags
and config-defaults
are different config maps. Modules using the config store are only minimally affected by this: they use config store the same way, i.e. by passing the context, just specify the flags under FeatureFlags
"option group" as Defaults
and FeatureFlags
are both structs under the same config
module.
If combining the two sets is preferred, please let me know and I will update the PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to like having it seperate 🤔
/cc @sbwsg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, feature-flags
is already a separate ConfigMap. If we wanted to merge it with config-defaults
then I'd prefer that be a discussion/PR unto itself rather than mix it in with a behavioral change such as this. @afrittoli if you prefer to go that route do you want to pursue it at an upcoming WG?
dd6ff21
to
d0fa286
Compare
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
return &Config{ | ||
Defaults: defaults, | ||
Defaults: defaults, | ||
FeatureFlags: featureFlags, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tend to like having it seperate 🤔
/cc @sbwsg
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification.
My intention was not to merge the configmaps necessarily, I was only trying to understand if we had to duplicate the logic that manages the configmaps.
It's fine for me to go ahead as it is, we can still factor things up later if possible.
Oh I see, apologies! This makes perfect sense to me. Agree on it being a possible improvement! |
@@ -0,0 +1,40 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did these vendor
changes come from? I see vendor/modules.txt
updated but I have to confess I don't really understand how that plays with go.mod
/ go.sum
. Did you manually update that file? Or was it somehow automatically updated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the review. The changes in vendor/modules.txt
were made by the hack/update-deps.sh
script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really understand why vendor/modules.txt would be updated but not go.mod or go.sum but 🤷.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Feature flags configuration is now tracked by the config store. This allows watching for the corresponding config map changes, removing the need to call kubernetes API to get the feature flags config map every time a pod is created. Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
Taskrun reconciler now uses a configmap watcher for `feature-flags` configmap to remove the need for an extra Kubernetes API call to get the configmap's value every time a pod is being created. Signed-off-by: Arash Deshmeh <adeshmeh@ca.ibm.com>
d0fa286
to
64da2b5
Compare
The following is the coverage report on the affected files.
|
/retest |
/lgtm |
Changes
Taskrun reconciler now uses a configmap watcher for
feature-flags
configmap to remove the need for an extra Kubernetes API call to get the
configmap's value every time a pod is being created. Fixes #2117.
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes